CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/hobby/gim_308.zip/GIM11H.DOC

Text File | 1993-09-09 | 16KB | 348 lines

          CHAPTER 11     LISTS OF SIMILAR PERSONS, FAMILIES AND NOTES

                                      OR

          SEARCHING YOUR FOLDER FOR SPECIFIC INFORMATION


PART H:  ADVANCED EXAMPLES; ARCANE WHERE COMMAND SYNTAX...

WARNING!!!

          This section is NOT FOR THE FAINT OF HEART!!!

          This section covers advanced topics in GIM LISTS WHERE
          command construction, and should only be attempted by those
          persons who feel very, very comfortable with the basics.

          Before reading this section, you should be very familiar with
          the sections of this chapter up to this point, and you should
          have played around with the examples in this chapter and used
          GIM LISTS on your own folder before continuing.

          That having been said, turn back now, or read the rest of
          this section at your own risk!

PURPOSE...

          WHAT THIS SECTION WILL DO FOR YOU

          As we've said elsewhere, GIM LISTS was designed to be a very
          powerful database querying mechanism.  It was designed, in
          short, to allow you to search for anything you can imagine.

          The GIM LISTS tools introduced up to this point are able to
          handle 95% of the things you may want to look for.  However,
          there are some things that you may want to look for which
          simply can't be done with the basic GIM LISTS commands.

          Therefore, the extensions to GIM LISTS described in this
          section were added to augment the power of GIM LISTS, and to
          handle those few cases where the basic tools don't suffice.

          These extensions are referred to tongue-in-cheek as "arcane"
          commands, because they won't be needed all that often, and
          because their syntax (admittedly) isn't very intuitive.  But
          they are useful to know about, because they greatly increase
          your power in those occasional situations where you need to
          search for something unusual.

OVERVIEW...

          AN OVERVIEW OF THE REST OF THIS SECTION

          The rest of this section will cover the following situations,
          which the basic tools can't handle without some help.  Along
          the way, we'll discuss the problems and solutions for each of
          these situations:

          1.  You want to create a list persons who have a place name
              in "Niger", but not "Nigeria", or "Mexico" but not "New
              Mexico".  Or you want to create a list of persons who
              have a note about "Italy" but not one about "Rome".  Or
              you want to create a list of families with at least one
              child named David who was born in Wisconsin.

          2.  You want to create a list of persons who lived at least
              80 years.  Or who were married to each other for at least
              10 years before one of them died.  Or who were baptized
              before the age of eight.

          3.  You want to create a list of persons whose LDS temple
              ordinances were performed in temples which didn't exist
              at the time -- such as a Salt Lake Temple sealing in
              1877, or a Nauvoo Temple endowment in 1946, or an
              Endowment House sealing in 1906.

CASE ONE:  THE COLON OPERATOR

          Suppose you want to create a list of persons who have a place
          name -- any place name -- in "Niger", but not "Nigeria", or
          in "Mexico" but not "New Mexico".

          You already know how to search for any place name in Niger.
          That's done like this:

          WHERE any place name contains "Niger"

          But that doesn't rule out place names in "Nigeria", and if
          you want to leave them out, you're out of luck -- you'll get
          them anyway.

          Your first instinct might be to do this, and you'd be wrong:

          WHERE any place contains "Niger" and
                any place doesn't contain "Nigeria"

          This would select people from Niger, but it wouldn't keep out
          people from Nigeria.  If you have someone who is born in
          Nigeria and who died in Arizona, he or she would be selected,
          because he or she has a place name that contains "Niger", and
          another one (Arizona) that doesn't contain "Nigeria".

          Part of the reason for the confusion is that the following
          WOULD work:

          WHERE birth place contains "Niger" and
                birth place doesn't contain "Nigeria"

          This looks similar to the problem WHERE command above, which
          doesn't work.  However, this one DOES work, as long as you're
          only interested in a specific place for each person, such as
          a birth place.

          The problem here is that once you include the ANY and ALL
          modifiers, you open yourself up for ambiguity.

          The solution to this problem is to introduce the Colon
          operator (:), and to use it like this:

          WHERE any place : contains "Niger" and
                            doesn't contain "Nigeria"

          (Note that there must be at least one space before and after
          the colon itself.)

          So why does this WHERE command work if the earlier WHERE
          command doesn't work?

          Because "any place contains something" refers to a set of
          things, and "any place doesn't contain another thing" refers
          to a set of things, and because each of these sets is
          evaluated separately.

          But when we pull the "any place" out in front of a colon
          operator (:), we evaluate everything after the colon at the
          same time for each place.  That way, someone who was born in
          Nigeria wouldn't pass the test, although someone born in
          Niger would.  (Also, someone born in Nigeria who died in
          Niger would naturally also pass the test.)

MORE USES FOR THE COLON OPERATOR

          Now that you've seen the colon operator, you can imagine what
          other uses it has.  Just as with Niger and Nigeria, you can
          use it to filter out people from Mexico from those from New
          Mexico.

          You have a similar problem when you search through a person's
          notes.  If you look for notes about Italy, but not about
          Rome, you'll get into trouble with this command:

          WHERE any note contains "Italy" and
                any note doesn't contain "Rome"

          ... for the same reason.  If the christening source note
          contains "Rome, Italy" and the death research note doesn't
          say anything about Rome, then this person will be selected,
          even though you didn't want to select him or her.

          The solution, of course, is this:

          WHERE any note : contains "Italy" and doesn't contain "Rome"

          The story is the same if you want to create a list of
          families with at least one child named David who was born in
          Wisconsin.  (I know; it's a far-fetched example; but then
          again, that's why these are called "arcane commands"!)

          This one won't work:

          WHERE any child given is "David" and
                any child birth place contains "Wisconsin"

          ... because it will select any family with a child named
          David -- whether or not he was born in Wisconsin -- as long
          as he or some OTHER child WAS born in Wisconsin.

          The solution is this, which will work:

          WHERE any child : given is "David" and
                            birth place contains "Wisconsin"

          The moral of this story is:  pay close attention when you
          want to use the ANY modifier in the same WHERE command with
          an AND conjunction.  That situation is an ideal time to use
          the Colon operator.

CASE TWO:  THE PLUS AND MINUS OPERATORS

          By now, you know how to compare date variables.  For example,
          you know how to search for persons who died before they were
          born, like this:

          WHERE death date is before birth date

          This is an ideal way to search for errors in your folder.  I
          should know; I've used it, and found several typos and other
          problems in my folder!  However, although this gives us the
          ability to find gross errors in our data, it is much too
          limited.

          Suppose you want to persons who died before they were ten
          years old.  How would you do it?  The concept is simple:  we
          clearly want to modify the WHERE command above so that it
          reads something like "WHERE death date is before birth-date-
          plus-ten-years".

          So as not to keep you in undue suspense, that concept is
          translated into WHERE command syntax as follows:

          WHERE death date is before birth date PLUS 100000

          Any date variable can be modified with a PLUS or MINUS
          keyword in this way.  The value after the PLUS or MINUS
          keyword is of the form YYYYMMDD, where YYYY is a number of
          years, MM is a number of months, and DD is a number of days.
          Therefore, 100000 should be interpreted by splitting it up
          into three parts -- in other words: 10 (years), 00 (months),
          and 00 (days).

MORE USES FOR THE PLUS AND MINUS KEYWORDS

          Having said that, you should be see how to create a list of
          persons who lived at least 80 years.  The WHERE command would
          look like this:

          WHERE death date is after birth date PLUS 800000

          It is also straightforward how to create a list of persons
          who were baptized before the age of eight.  That WHERE
          command would look like this:

          WHERE baptism date is before birth date PLUS 80000

          It is a little less obvious how to create a list of couples
          who were married to each other for at least 10 years before
          one of them died.  Study the following WHERE command, which
          is applied to a list of families:

          WHERE  husband death date is after marriage date PLUS 100000
                and wife death date is after marriage date PLUS 100000

WARNINGS ABOUT THE PLUS AND MINUS MODIFIERS

          There are two things to be aware of with regard to these
          modifiers.

          WARNING NUMBER ONE:

          The first is that GIM LISTS is smart enough to ignore date
          comparisons when dates don't exist.  In other words, if
          you're looking for people born before 1700, GIM LISTS is
          smart enough to ignore people whose birth dates are missing,
          and it doesn't report them to you as persons born before
          1700.  However, all bets are off when you use the PLUS and
          MINUS modifiers.  When you use them, GIM LISTS is unable to
          distinguish very early dates from missing ones.

          To get around this problem, you should combine PLUS and MINUS
          searches with IS COMPLETE or IS ACCEPTABLE operands.  So for
          example, to be absolutely accurate, the test above for
          couples married at least ten years should really look
          something like this:

          WHERE marriage date is complete and
                husband death date is complete and
                wife death date is complete and
                 husband death date is after marriage date PLUS 100000
                and wife death date is after marriage date PLUS 100000

          WARNING NUMBER TWO:

          When adding years, months, and days to a date with the PLUS
          and MINUS modifiers, GIM LISTS isn't smart enough to carry
          excess days and months into the next month and year.  It
          isn't smart enough, in other words, to add six months to
          December 1805, and get (as you might expect) May, 1806.

          That's because it was only designed to handle gross changes
          in time, such as "ten years" or "eighty years".  It can still
          handle the months and days okay, as long as it isn't expected
          to carry them over.

          To be brutally, graphically descriptive, what's actually
          going on is this:  GIM LISTS takes the year and translates it
          into a number.  For example, December 23, 1805, becomes
          18051223.  If you then add 38 years, six months and four days
          -- which you specify as 380604 -- to this value, GIM LISTS
          simply adds them, resulting in 18431827.  As you can see, the
          result is "the 27th day of the 18th month of 1843", which
          really doesn't mean a whole lot, and GIM LISTS will behave in
          unpredictable ways when it tries to compare this value to a
          "real" date.

          The moral of the story is:  use months and days at your own
          risk, realizing that they might work well, and they might
          not.  Your best advice is to stick with comparing years this
          way.

CASE THREE:  THE PLACEBEG AND PLACEEND OPERANDS

          You already have the tools to handle most of the situations
          that connect dates with places.  You can, for example, find
          persons born in Connecticut before 1700.  With the colon
          operator, you can find any event which took place in a
          certain place at a certain time.

          In the case of LDS temples, however, this is a little more
          problematic.  You can still do the same sort of thing, by
          searching for any LDS event in the Salt Lake Temple before it
          opened in 1893.  But doing so requires that you already know
          the opening and closing dates for each of the LDS temples.
          Moreover, it doesn't give you the flexibility of comparing
          opening and closing dates for each of the temples in a single
          command.

          To address this concern, GIM LISTS provides PLACEBEG and
          PLACEEND operands.  These are date operands, and they only
          have meaning for LDS events -- baptism, endowments, and
          sealings.  They represent the opening and closing dates for
          each temple, and they work like this:

          Suppose you want to create a list of persons whose LDS temple
          ordinances were performed in temples which didn't exist at
          the time -- such as a Salt Lake Temple sealing in 1877, or a
          Nauvoo Temple endowment in 1946, or an Endowment House
          sealing in 1906.

          Rather than searching for each of these things on a temple-
          by-temple basis, you can issue a WHERE command like this:

          WHERE endowment date : is before PLACEBEG or
                                 is after PLACEEND

          You know already that this command tells GIM LISTS to search
          through each person's endowments.  For each of these endow-
          ments, it compares the date of the endowment to the opening
          date of the place of that endowment (PLACEBEG), and is also
          compares the date of the endowment to the closing date of the
          place of that endowment (PLACEEND).

          This capability provides a quick way to search your folder
          for possible typos or other data inconsistencies.

          Please note:  if an LDS baptismal date exists, and if an LDS
          baptismal place name contains the word "living", it is always
          true that the baptismal date is between PLACEBEG and PLACEEND.